[アップデート]AWS Firewall Managerは、「他のVPCのセキュリティグループIDを参照」するセキュリティグループを自動作成やリソースに適用できるようになりました

[アップデート]AWS Firewall Managerは、「他のVPCのセキュリティグループIDを参照」するセキュリティグループを自動作成やリソースに適用できるようになりました

Clock Icon2023.10.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

AWS Firewall Managerは、「他のVPC上のセキュリティグループIDを参照」するセキュリティグループ(以降、SG)を管理できるポリシールールが追加されました。

Firewall Manager は、AWS Organizations内にあるアカウントで、AWS WAFやSGなどの設定を一元的に管理するセキュリティサービスです。

先に用語の説明をします。

Firewall Managerでは、プライマリセキュリティグループとレプリカセキュリティグループの2つが存在します。

  • プライマリSG
    • 各アカウントのリソースに割り当てたいSGをプライマリSGとして、Firewall Managerに設定する
    • Firewall Managerで設定したプライマリSG自体は、リソースに割り当てられません。レプリカSGが割り当てられます。
  • レプリカSG
    • Firewall Managerによって、プライマリSGと同じ設定内容のSGがコピーされ、レプリカSGとして対象アカウントに自動作成され、リソースに割り当てることもできます。
  • Firewall ManagerでのSGの管理機能
    • 対象のアカウント内にレプリカSGを作成したり、リソースに割り当てる
    • SGルールを監査し、準拠していないルールを修正する
    • 未使用および冗長なSGを検出する

下記は、対象のアカウント内のリソースにレプリカSGを適用するイメージ図です。

従来、Firewall ManagerのプライマリSGは、アウトバウンドやインバウンドルールのうち、送信先に「他VPCのSGのIDを参照する」ルールはレプリカSGとして自動作成することはできませんでした。

送信先に「他VPCのSGのIDを参照する」というのは、以下のような設定のことです。

アップデートによって、送信先に「他VPCのSGのIDを参照する」SGもレプリカSGとして、自動作成したり、リソースに割り当てることができるようになりました。

これによって、ピアリング接続された各VPC内の各リソースに割り当てられたSGは、相互参照することができ、導通することができます。また、Firewall ManagerでそのSGを管理できます。

利用例

具体的な使用例を、構成図をもとに説明します。

下記の構成は、アカウントAとBに存在するEC2インスタンス(①と②)が、アカウントBのプロキシサーバー経由でインターネットに出る構成です。

インターネットの出口を1つのVPCに集約させる構成は、よくありますね。

この構成の場合、①と②のEC2インスタンスのSGは、プロキシサーバーのSGのIDを参照し、アウトバウンドルールを許可する設定が必要です。

そのルールが設定されたSGは、本来、アカウントごとに手動で作成する必要がありますが、今回のアップデートによって、Firewall ManagerからプライマリSGを設定すると、各アカウントにレプリカSGが自動作成され、対象のEC2インスタンス(①と②)に自動で割り当てることができます。

下記のイメージです。

メリットとしては、アカウントごとに手動でSGを作成する必要がなくなり、Firewall Managerで一括管理できる点です。修正する際も、プライマリSGのみを修正すれば、全てのレプリカSGに反映されます。

前提条件

Firewall Managerを利用するには、以下を設定する必要があります

  • Organizationsに参加する
  • Firewall Manager 管理者アカウントを設定する
  • Config を有効にする

また、今回は、下記の構成で検証してみるため、以下を事前に設定しました。

  • AアカウントをFirewall Managerの管理アカウントにした
  • AアカウントとBアカウントともにConfigを有効化
  • AアカウントとBアカウントは、ともに同じリージョン(今回は東京リージョン)
  • EC2インスタンス3台とも起動済み
  • VPCピアリングし、ルートテーブルも反映済み  

試してみた

以下の内容をやってみました。

  1. EC2インスタンスのタグ付け
  2. プライマリSGの作成
  3. Firewall Managerのセキュリティポリシーの作成
  4. EC2インスタンスの導通確認

EC2インスタンスのタグ付け、プライマリSGの作成

EC2のタグ付けとプライマリSG用のSGを作成します。

プロキシサーバー以外の①と②のEC2インスタンスに、タグを付与します。

  • キー名:Firewall Manager
  • 値:ON

管理アカウントであるアカウントAで、プライマリSGを作成します。

outbound-sgという名前で、以下の設定で作成しました。

- タイプ プロトコル 送信先
インバウンド - - -
アウトバウンド すべてのトラフィック すべて プロキシサーバーのSGのID

作成後、アウトバウンドルールを見ると、送信先には、BアカウントID/プロキシサーバーのSGのIDと、BアカウントのアカウントIDも記載されてました。

Firewall Managerのセキュリティポリシーの作成

Firewall ManagerでSGのセキュリティポリシーを作成します。

  • サービス:Security group
  • ポリシータイプ:Common security groups(共通SG)
  • Region:東京リージョン

ポリシールールは、今回のアップデート内容である下記を選択します。

  • "Distribute security group references from the primary security group to the security groups created by the policy"
    • プライマリSGからポリシーによって作成されたSGにSG参照を配布する

プライマリSGは、先程作成したoutbound-sgを選択します。

また、ポリシーアクションは、自動修復を選択します。

対象のアカウントは、アカウントAとアカウントBを選択します。

リソースタイプは、EC2インスタンス、リソースタグは、キーFirewall Manager、値ONにします。

先程の自動修復設定によって、対象のタグを付与した①と②のEC2インスタンスに対して、レプリカSGを自動的に割り当ててくれます。

この設定で、セキュリティポリシーを作成します。

数分後、①と②のEC2インスタンスに対して、レプリカSGが自動的に割り当てられました。

下記は、プロキシサーバーと同じアカウントBに存在するEC2インスタンス(②)に割り当てられたレプリカSGです。

FMManagedSecurityGroup..-プライマリSGのID-VPCのIDという名前でした。

アカウントAのEC2インスタンス(①)に割り当てられたレプリカSGです。

VPCピアリング先のEC2インスタンスの導通確認

EC2インスタンス(①と②)からプロキシサーバー(プライベートIP:10.2.139.187)にpingしてみます。

どちらのEC2インスタンスからもプロキシサーバーにpingが通りました。

最後に、セキュリティポリシーを削除します。

セキュリティポリシーを削除すると、レプリカSGもきれいに削除されました。

最後

今回のアップデートでは、Firewall Managerは、他のVPC上のSGのIDを参照するSGを管理できるポリシールールが追加されました。

今回の利用例で示した構成の場合、アカウントごとに手動でSGを作成する必要がなくなり、Firewall Managerで一括管理できる点がうれしいですね。

修正する際も、プライマリSGのみを修正すれば、全てのレプリカSGに反映されますので、運用管理が楽になります。

参考

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.